■JAN. 23. 2009 1 1:33AM 



NAVTEQ CORP 



RECEIVED 
CENTRAL FAX CENTER 



NO. 549 



P. 14 



JAN 2 3 2009 



AppL No. 10/798,459 

Declaration of prior invantiou 

Reply to office action of October 28, 2008 



PATENT 
Case No. N0184US 



IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 



Appl, No. 

Applicants 

Filed 



10/798,459 

Kurt Brooks Uhlir, et al. 
March 11,2004 

METHOD AND SYSTEM FOR USING GEOGRAPHIC DATA 
IN COMPUTER GAME DEVELOPMENT 



Titled 



DECLARATION UNDER 37 C.F.R. S 1.131 



The undersigned, KURT BROOKS UHLIR, CHRISTOPHER DOUGHERTY, 
MICHAEL V. SHUMAN, and ROY CASINO, hereby declare that: 

1. We are co-inventors of the invention described and claimed in the above-identified 
patent application. 

2. Before May 21 , 2003, we invented a new method for deriving products from a source 
geographic database. Part of this new method included using or extracting data from a source 
geographic database to provide a dataset used in developing video games that depicted real 
geographic locales as part of play scenarios. An application programming interface used for 
developing the video games from the specific dataset was also provided. The source geographic 
database included navigation attributes including data representing road segments, and the source 
geographic database was also used to provide a dataset to develop real-world navigation systems. 

3. Before May 21, 2003, we prepared invention disclosure statements describing our 
inventive ideas. We provided the invention disclosure statements to the Legal Department of the 
assignee of the subject patent application. A copy of an invention disclosure statement prepared 
by us prior to May 21, 2003 fully disclosing the claimed invention is attached hereto (Exhibit 1). 

4. All statements made herein of my own knowledge are true and that all statements 
made on information and belief are believed to be true, and further these statements are made 
with the knowledge that willful false statements and the like so made are punishable by fine or 
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imprisonment, or both, under Section 1001 of Title 1 8 of the United States Code, and that such 
willful statements may jeopardize the validity of the application or any patent issuing thereon. 



KURT BROOKS UHLIR Date 
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navigation technologies corporation 
invention disclosure statement form 

(Return electronic copy and 
fully executed hard copy to Legal Department) 



(to be filled oat by Legal Dept.) 



Shorthand Name for Invention: Ideas for a "Game API" for Use in Creating Games 

Developers Who Contributed to Invention: 1. Roy Casino 

3. Chris Dougherty 

S. 

7. 



2. Mike S human 

4. Kurt Uhlir 

6. . 

S- 



Date (or Month) on Which Development Began; 4 




If Known, First Date (if any) on Which Development was: 




(a) described in a CONFIDENTIAL document released outside of NTC 




(b) described in a CONFIDENTIAL conversation with a non-NTC employee 




(c) described in a NON-confidential document released outside of NTC 




(d) described in a NON-confidential conversation with a non-NTC employee 




(e) included in any version of a product released outside of NTC 




(f) used internally at NTC in the normal course of operations: 




(g) discussed at a Brainstorming Session for IDS No. 




Summary of Invention; 



NTC currently offers SDAL and NavTools for use in creating in-vehicle navigation applications. Furthermore, NTC offers 
RTM for use in creating real-lime on-board or off-board applications. The idea proposed in this IDS is for an AFI that will 
offer interfaces for creating navigation based gaming applications. The general idea of NTC offering a game API as well as 
some specific ideas arc proposed in this IDS. The ideas and related concepts for the game$ are proposed in numerous other 
IDS forms. This IDS directs its focus on the new and unique ideas necessary for the gaming API. (Other documents exist 
that detail the business reasons justifying NT's interest in being a part of the huge game market,) 



Key Words for Invention: . 



Navigation, games, API, Ground, Truth, Gaming, Electronic Games, Video Games, LBS, LBG 



Advantages of Invention (to the extent known): 



Allows one to easily create applications using NAVTECH data 

Allows NAVTECH data to become more widely known based on name recognition through people playing games on PCs, 
phones, internet, etc. 

Opens up a new business market for NAVTECH data simply by offering a new API 

API could be based heavily on SDAL and NavTools code making development more effective 



Detailed Description oflnvention 

* describe f unction(s) p erformed 

* describe with particularity the way in which each function is achieved (e.g., if the invention 
is a process, describe each step of the process): 



CONFIDENTIAL 

PAGE 16124 ' RCVD AT 112312009 12:31:27 PM [Eastern Standard Time] ' SVR:USPT0-EFXRF-6/29 * DNIS:2738300 ' CSID:31 28947228 * DURATION (mm-ss):03-32 



RECEIVED 

•JAM. 23. 2009 1 1 : 33AM NAVTEQ CORP CENTRAL FAX CENTER 

r — JAN 2 3 2009 



NO. 549 



P. 17 



The Game API will offer functions broken into four key areas that differ from current NTC APIs: 



I. 

in. 

IV. 



Functions to convert NAVTECH data to other formats suitable for games 

Functions for high-speed display necessary for games 

Functions for aesthetically pleasing display formats necessary for games 

Function to easily integrate NAVTECH data with other data content necessary for games 



Each of the four areas will be described in more detail below. 



I. 



Functions to convert NAVTECH data to other formats suitable for games 



Overview: 



These functions allow conversion of NAVTECH data to formats for use with 3-d display, cell phone display, 
PC gaming via internet display, and others. The idea here is that the NAVTECH database should remain 
focused on navigation applications. In turn, these functions will use the NAVTECH database, but offer data 
necessary for game play in one of the game formats. For example, a "cannonball run" type of racing game 
would require the NAVTECH data to appear in 3-d format as if a car were driving the roads. This would allow 
drivers to race across the United States (or other region), allow them to choose to drive on any road, allow the 
games to drive realistic routes with real knowledge of speed limits, signage, and more integrated into their 
game play. 



3-d display: The 3-d display functions will allow games to "travel" along roads from a driver's perspective. 
For example, a driving game could allow one to race a route from Chicago to St. Louis. 

Functions: 

3jljiisplay(UnkID f location, direction_of_travel, Displaylnfo) 

link ID (input) . . . the NAVTECH link ID of the desired link for display 

location (input). . .the actual location along the link (expressed in percentage along the link) 

toection_ofjravel (input). . .direction of travel (from reference node or to reference node) 

Displaylnfo (output). ..a structure (not defined here) that holds all information necessary for displaying a 3-d 

image of the road and related attributes. The image drawn on a display using mis information would be a 

computer rendered view of what a driver would see from a car located on the road at this point. 



internet_display: The internet display functions will allow incremental updates of internet displays for game 
play. For example, a first display screen would show full detail of a certain geographic area in 2d or full 3d. 
Further updates to the screen will only send necessary information to indicate changes to the current display. 
This method of sending only changes will allow faster updates necessary for game play over the internet. A 
function like this could allow a set of gamers across the nation connected only by internet connections to play 
competitive games based on NAVTECH data with each other in real-time. 

internet_display(region, 2d_3d Jlag, location, Displaylnfo) 

region (input).. .bounding box region to display 

2d_3djQag (input)... whether 2d or 3d display should be shown 

location (input). . . gamer's location on the requested map 

Displaylnfo (output)... a structure (not defined here) that holds all information necessary for displaying an 
image of the road and related attributes. Further updates to this display would only send changes to allow for 
fast transmission across internet connections and fast display updates. 



Example: 



Example: 



More: 
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Those are only two representative type functions that could exist in a game API. Clearly, numerous additional 
functions will be necessary in the actual implementation. 



Current NavTools display tools are not optimized for high-speed updates or continuous movement. The game 
API will require functions that support these types of scenarios. This will allow a driving game, for example, 
to give the appearance that a vehicle is being driven along a road way created using NAVTECH data. 

Requirements: 

No new functions will necessarily be required versus current NavTools functions as much as more optimization 
will be required. Concepts such as high speed polygon display and other video game derived display 
technologies will have to be incorporated irrto the game API tool set. This integration of video game 
technology into a game API will allow the NAVTECH database to be drawn in 2d or 3d at very high speeds. 

HI. Functions for aesthetically pleasing display formats necessary for games 



Current NTC APIs display maps for navigation purposes. The game API will require changes so that displays 
can be oriented to more aesthetically pleasing display formats. Formats that include road widths and lane 
stripes will be incorporated into the display functions. Furthermore, attributes such as road names will be 
optional in the display as road names may not always be necessary for games. Moreover, games may choose to 
leave off the road names for the sake of speed. 

Requirements: 

The display formats for games wifl require that NAVTECH data (intended for navigation applications) will 
have additional visual information attached during the process of preparing for display. For example, a game 
may query for a display that includes stripes on the lanes and shoulders along the edges of the road. Further 
examples are the inclusion of road signs so that a game player sees a speed limit sign, for example, pass by as 
he/she drives. 

Function: 

setjrfisplay j>arameters( visual jttrributejisi) 

visual_attribute_list (input)... this parameter allows one to set visual attributes such as whether lane stripes 
should he added to the roads for display, whether signs should be added to ihe display, whether shoulders or 
curbs should be added, and other attributes of this sort intended to visually aid a driver playing a game and not 
necessarily aiding in navigation. 

IV. Function to easily integrate NAVTECH data with other data content necessary for games 



Many games will also desire to integrate information such as the look of other vehicles on the roads, traffic 
information on the roads, the look of buildings along the road, and other such examples. The game API will 
allow the game designers access to the polygonal display tools so that these additional features could easily be 
integrated with the NAVTECH data. For example, a game designer may want to populate the roads being 
driven with actual vehicles on the market. In that case, the game designer would obtain vehicle modeling 
information from other sources and feed it to the game API so that the vehicles could be placed on a 3-d 
NAVTECH road map display. 



n. 



Functions for high-speed display necessary for games 



Overview: 



Overview: 



Overview: 



Function: 
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integrate^extemaljnformation(palygonaljnfom location) 

polygonal ^information (input) ... the polygon modeling infonnaiion necessary to render a particular geometrical 
shape such as a building or vehicle. 

location (input). . .the location 10 display the polygonal Jnformation. This would allow one to place buildings 
along the road or other vehicles along the road. 



Please place an "X" next to the appropriate statement; 
X No design documents exist 

The following design documents exist (and copies are attached): 



Signature: 

(of prcparcr-devclopcr) 

Type Name: Roy Casino 
Signature^) of Contributing Developers: 

1. Name: 

2. Name: 

3. Name: 

4. Name: , 

5. Name: 

6. Name: . 

7. Name: 



Dated 



Datc:_ 
Date:_ 
Date:_ 
Date:_ 
Date:_ 
Date:_ 
Date: 
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